[レポート]SBOMとセキュリティの透明性 - すべてを統合する方法 - CODE BLUE 2024 #codeblue_jp
こんにちは、臼田です。
みなさん、セキュリティ対策してますか?(挨拶
今回はCODE BLUE 2024で行われた以下のセッションのレポートです。
SBOMとセキュリティの透明性 - すべてを統合する方法
ソフトウェアに何が含まれているのかを知るというアイデアは、急進的な考えから「SBOM(Software Bill of Materials)」という流行語に変わった。しかし、SBOMはどこへ行こうとしているのだろうか。また、セキュリティにおける他の動き、特に政策や規制に関する動きとどのように関わっていくのだろうか。本講演では、SBOMがどこから来て、どのようにして世界的なコミュニティになったのかを振り返り、現在のギャップを明示し、コミュニティがどのようにそれらに対処しようとしているのかを説明する。しかし、もちろんSBOMだけですべての問題が解決するわけではない。SBOMの前に、より多くのCoordinated Vulnerability Disclosure(CVD)が必要である。SBOMが整備された後は、新しいCVE標準を含む質の高い脆弱性データと、より優れたソフトウェア識別子が必要になる。そして、情報過多にならないためには、プロプライエタリ・ソフトウェアとオープン・ソース・ソフトウェアの両方について、VEX(Vulnerability Exploitability eXchange)と機械可読なアドバイザリが必要となる。 これらすべてを見渡し、ソフトウェアセキュリティと対応の未来について、より良い計画を立てるための全体図を描こう。
Speakers: Allan Friedman
レポート
- セキュリティの新たな進化について話したい
- SBOMとセキュリティの透明性について
- アメリカサイバーセキュリティ安全保障局に所属している
- サイバーセキュリティについて話し始めたら止まらない男として有名です
- 今回の話は飛行機を飛びながら組み立てる話
- SBOMとはなにか
- アメリカでSBOMプログラムを行っている
- 日本でも使っている
- リスクは常に変化している
- 見つかっている脆弱性の数は増えている
- 攻撃者はただくるものを使っているだけではない
- サプライチェーンはサイバーセキュリティのアキレス腱といってもいい
- 十分保護されていない
- サプライチェーンリスクについて考えると様々
- 再利用されるべきではないコードが利用されるなど
- 透明性について考える
- ソフトウェアの中に何が入っているのかを知る
- 私はキットカットが好き
- ピーチフレーバーは日本でしか手に入らない
- 材料表示がついている
- ソフトウェアよりもお菓子の方に透明性を求めているのはおかしい状況では?
- 透明性から始まる
- SBOMはソフトウェアの材料表示
- それぞれのコンポーネントについて多くの情報が必要な訳では無い
- バージョン番号や識別子など
- 独自のソフトウェアであればそのバイナリのバージョンなど
- なぜこれらが必要か?
- 透明性が必要だから
- ソフトウェアの中身がわからなければ安全ではない
- 商用のソフトウェアを購入する場合もあればOSSを採用するときもあるが、内容を知る必要がある
- 運用時も同じ
- ソフトウェアの中身を理解したい
- Log4jのときもSBOMがあればすぐに対応できたはず
- 国の対応について
- アメリカでは大統領令がでてSBOMについて対応していく必要性がある
- インドでも
- 日本でも経済産業省からガイダンスが出た
- 欧州のサイバーレジリエンス法でもSBOMが対象になっている
- 我々が使っている無料のツール
- すべてが品質が高いわけではない
- 医療機器でもSBOMが必要
- 購入できる市販のツールはたくさんあってもニーズを満たすものは1つもないといっている
- 我々はソフトウェアの定義を変えないといけない
- 定義してユースケースを決める
- 世界的にこれが調和するようにしていく必要がある
- すべての国が同じ認識を持てるようにする
- 一つの概念を定義するだけではない
- ソフトウェアのアイデンティティをどう定義するか
- Netskopeの人
- ソフトウェアに名前をつけることは簡単ではない
- -をハイフンと呼ぶかダッシュと呼ぶかも違う
- 拡張性のあるソリューションが必要
- 脆弱性はどこから来ているのか
- SBOMはどこから来ているのかを理解できる
- 脆弱性を調べてレポートしていく必要がある
- 誰に連絡する必要があるか
- 評価とバリデーション
- 一般に発表していく
- CVD
- 共通的脆弱性の開示
- あまり取り上げられていない
- 昔は疑問視されていたが今は機能している
- うまくやるためには
- 実現するためにはリサーチャーが組織で仕事をしやすくする
- 建設的にやり取りする
- リサーチャーが法的に問題にならないようにする
- 脆弱性の情報の質について考える
- CISAではエンリッチメントに対応していっている
- 情報を拡充する
- 最終的に各組織が重要な脆弱性について判断できるようにしていく必要がある
- すべての脆弱性がリスクをもたらすとは限らない
- すべての脆弱性が利用可能である、exploitableであるというのはトリッキーで使いづらい指標
- そこでVEX
- Vulnerability Exploitablitity eXchange
- その脆弱性が使われているかどうか
- コンポーネントが使われていないか
- こういった情報を読み取れる形で提供できればよい
- 将来はどうなっていくのか?
- 飛びながら組み立てる飛行機の話に戻る
- 窓がまだついていない時に飲み物を注ぐとこぼれるかも
- つまりツールは使ってほしいがパーフェクトじゃないよってこと
- データの質がいいわけではない
- データの質が良いだけでも活用できるわけではない
- 良いデータが手に入ることは目的ではない
- そこからインテリジェンスに対応したい
- 自動化したい
- 自動化なしで進めているものがあるなら間違っている
- もっと自動化、つまりツールが必要
- データを自動的に消化できないといけない
- データをどう使ったらいいか
- いまツールを作るところを進めている
- モジュール化が大事
- ツールもデータも組み合わせて使えるように
- プラス、一部を改善しながら他のものを壊さないようにする必要がある
- SBOMでは互換性も大事
- SBOMのツーリングに興味があるベンダーに持ち寄ってもらう
- 出来上がったSBOMを比較して分析しようとしている
- どうやってモジュール的に組み合わせるか検討している
- EOLの情報についてもSBOMに組み込むべきと考えている
- 価値のあるデータがどんどん増えている
- それらを排除するのではなく、新しいデータを取り込めるようにしていきたい
- 興味があるならCISAと連携してほしい
- 飛びながら組み立てる飛行機の話に戻る
感想
お菓子の材料表示からSBOMの必要性にアプローチする話は面白いですね。
食品の安全性と同じように我々はソフトウェアの安全性について考えていく必要があるし、CISAの思想に乗っかってソフトウェアのあり方を変えていく必要がありそうですね。